• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    PORTFOLIO WITH MULTIPLE TRADE CHANNELS FOR AUTHENTICATED TRANSACTIONS. An electronic phone-based wallet providing authenticated transactions across multiple trade channels is described. The electronic wallet can be used for point-of-sale payments, remote mobile payments and / or network-based payments, and can use authentication tools such as off-network PINs, secure code PINs and network PINs.
    公开号:BR112013003369A2
    申请号:R112013003369-0
    申请日:2011-08-12
    公开日:2020-08-04
    发明作者:Shoon Ping Wong；Kenneth Chung Lem Moy；Celine Martig；Pablo Fourez；Alan Mushing；Fredrik Lundequist；Michael Ameiss；Michael Shaon
    申请人:Mastercard International, Inc.；
    IPC主号:
    专利说明:

    f “PORTFOLIO WITH MULTIPLE CHANNELS OF COMMERCE FOR AUTHENTICATED TRANSACTIONS” f Background of the invention The present invention relates to transactions for payment of items / services and, more particularly, to an electronic telephone-based wallet that provides authenticated transactions through multiple channels of trade.
    Both credit cards and debit cards are commonly used in the retail environment to purchase items and / or services. Such cards are popular with consumers, and merchants accept these cards as a necessary part of doing business, that is, they provide an effective substitute for cash and checks.
    These card-based draws are typically performed through multiple trading channels. For example, card-based transactions can be carried out in person at a retail store, via a computer connected to the Internet, via a mobile phone and / or through a company-based call center (for example, a number 1 -800 for a catalog company). These various transactions are carried out in different ways and therefore have different levels of fraud risk associated with them. In addition, the transactions mentioned generally require that the consumer has his card in hand to + present to the cashier in a retail environment, or enter the requested information through the Internet and over the phone. Those with knowledge in the field will recognize that the risk of financial fraud is greater during remote transactions because there is less ability for the merchant to verify the cardholder's identity and authenticity. It will also be recognized that in the current environment it is common for a consumer to carry their cell / mobile phone with them at all times. In fact, on many occasions the consumer is more likely to be carrying his phone than carrying his wallet. The companies tried to penetrate this trend by offering / facilitating several phone-based applications aimed at a full range of services. The recent growth of so-called “smartphones” has greatly increased the interest of companies in this area. As a result, an increasing number of transactions are likely to be carried out from a remote location, for example, ordering a product over the Internet while waiting on the line. However, as the number of remote transactions increases, so does the risk of financial fraud. There is, therefore, a need in the art for a method and system to authenticate electronic transactions through multiple channels of commerce. There is an additional need in the art for a method and system that operates in combination with a telephone (for example, a smartphone) to authenticate financial transactions whether initiated
    * personally, via the internet via an independent terminal, by making a call to a company's call center, and / or through a transaction 'started with the same phone.
    Finally, there is a need in the art for a method and system that allows a bank or other financial institution to reduce fees for merchants who perform remote electronic transactions by using improved authentication techniques, and limit / reverse the change in fraud liability for the merchant by such remote transactions.
    Summary of the invention The present invention provides a centric electronic mobile phone wallet that provides the guarantee of a virtual card terminal for online and offline purchases.
    A wallet server (for example, an application that runs on a cloud) and a synchronized company computer and mobile interface allows consumers to make purchases (which may include: retail, e-commerce, mobile, call center, etc. .) and use the mobile phone to authenticate against one of the authentication techniques linked to the chosen card (which may include: an offline PIN using a secure memory chip, a SecureCode MasterCard PIN, and / or an online PIN as an ATM PIN) where the required card and transaction specific processing and authentication method is handled by a central directory.
    The authentication process of the present invention allows participating banks to consider such transactions as more fully authenticated, which will allow them to lower the costs charged to merchants.
    The authentication process of the present invention - will also limit / reverse the change of liability for the merchant since those more fully authenticated transactions will have less fraud associated with them.
    This system with its various authentication mechanisms will preferably use a central hosted directory, which, when consulted by the wallet application during a transaction, will instruct the wallet how the transaction needs to be authenticated and processed, depending on the card used and the type of transaction.
    In all cases, the authentication result and authentication method will be communicated from the wallet to the merchant through specific transaction codes and / or transaction tokens that will additionally allow for appropriate risk marking, authorization processing, and enforcement rules. specific scheme and terms and conditions (for example, price, terms, change of responsibility, etc.) by the merchant buyer.
    The wallet facilitates authentication from multiple commerce channels and will leverage multi-band communication to facilitate transaction authentication.
    For retail purchase transactions (Point of sale (POS) / face to face (F2F)), the consumer can use the Contactless PayPass capabilities that can be a feature of a chip located in the phone.
    For higher transaction amounts where a PIN may be required, the wallet will prompt the user for the PIN on the phone.
    Upon successful authentication, it will be communicated from the wallet to the merchants or their * buyer directly for approval processing.
    For some remote purchase transactions (e-commerce, mobile or call center), the consumer will use their mobile phone and wallet capabilities as a virtual POS terminal.
    In this case, when the consumer makes a purchase (for example, through a computer or the mobile phone itself), the wallet will prompt the user for the PIN on the phone and allow a secure verification of the PIN value entered by the user, in a mode pure offline, against the algorithm associated with the secure element on the phone, using, for example, the EMV protocol, or in an online mode, by encrypting the PIN and transmitting it.
    Successful authentication will be communicated from the wallet to the merchant's clearance system to be transmitted to the Buyer for approval processing.
    For other remote purchase transactions (e-commerce, mobile or call center), the present invention is based on the pre-existing MasterCard SecureCode (MSC) system.
    It is considered here that the SecureCode protocol can be extended to include an Interface. new SecureCode Wallet Application (API) programming interface, to allow MSC validation on the wallet interface through the Wallet API, rather than through and an internet browser window / session to communicate with the authentication server of the Bank.
    To facilitate this, the mobile phone! will prompt the user to enter the MSC or PIN password on the wallet-driven interface on the phone and communicate securely with the ACS (the bank's MSC authentication server). Successful authentication will be communicated from the wallet to the merchant's clearance system to be transmitted to the Buyer for approval.
    This last step preferably replaces the pre-existing MSC Merchant software, thereby reducing the implementation requirements for the merchant.
    Finally, this interface will preferably allow configuration and reset of an MSC or PIN password, again without the need to use a separate browser window or session with the bank's authentication server.
    In this way, the system and method of the present invention provide an electronic wallet to authenticate transactions through multiple trade channels using the consumer's own mobile phone.
    The present invention provides better savings for merchants through lower rate structures, and limits the change in fraud liability for the merchant for remote transactions.
    The present invention is scalable in design to provide easy integration for merchants, and to avoid implementations and sales of issuer by issuer.
    It is also easy to deploy directly to consumers.
    Finally, the present invention will promote profitability by driving transaction volumes and revenues.
    7 Brief description of the drawings Figure 1 is a schematic representation of an authentication / payment system based on a mobile phone; Figure 2 is a flowchart representing the wallet application of the present invention being used in an e-commerce transaction originating through a computer, the wallet application cooperating with a secure element on the phone and an offline PIN; Figure 3 is a flowchart representing the wallet application of the present invention being used in an e-commerce transaction that originates through the computer, the wallet application cooperating with a SecureCode PIN for authentication; Figure 4 is a flowchart representing the wallet application of the present invention being used in an e-commerce transaction that originates through a telephone, the wallet application using an online PIN for authentication; Figure 5 is a flow chart representing the portfolio application of the present invention ”being used in an e-commerce transaction originating through one. click, the wallet application not being associated with an offline PIN, a SecureCode PIN and / or an online PIN; - Figure 6 is a flow chart representing an existing 3D Secure process; Figure 7 is a flow chart showing a new authentication process in accordance with the present invention; - “aura 8 is a flow chart showing a new authentication process in accordance with the present invention; Figure 9a is a flowchart showing the process of authenticating the wallet application using a SecureCode process; Figure 9b is a flowchart showing an authenticated wallet application being used for subsequent purchases; and Figure 10 is a flowchart showing an authentication system where the features of MPI and ACS have been incorporated into the wallet server.
    Detailed description of the invention Referring now to Figure 1, the present invention is centered around a mobile phone 10 associated with a payment card, for example, a credit card, debit card or prepaid card. The mobile phone is preferably capable of storing and / or running a wallet application 12, which is preferably a browser-based mobile application capable of storing selected information such as a cardholder name, changed card name, billing address / shipping, etc., locally on the phone or on a cloud server. In a preferred embodiment, the
    * mobile phone is a “smartphone”, and the wallet application is stored on a memory device located on the phone. It is envisaged here that the system and method of the present invention will allow payments through multiple channels of commerce, for example, a POS 14 payment, for example, through a PayPass terminal, a remote mobile payment 16 initiated by a mobile phone, and / or a network-based payment 18.
    As further described in figure 1, the present invention considers the use of several authentication tools including an offline PIN 20, a SecureCode PIN 22 and / or an online PIN 24. It will be recognized that the PINs mentioned above are currently in use in the market and, therefore, the use of such existing PINs can facilitate the implementation of this system. Of course, it is considered here that a new independent PIN (in addition to the PINs mentioned) can be created specifically for use with the present invention.
    Offline PIN 20 preferably uses an offline PIN verification process whereby the PIN entered by the consumer is verified by a secure element located on the phone 10. In this process, the wallet plays the role of a “virtual terminal”, interacting with the secure element, and after verification of the PIN, it passes the CHIP token (ARQC).: to the merchant for authorization. In this “virtual terminal”, the secure element serves the role! like the “card”. Offline PIN 20 can, for example, be used in connection with a PayPass payment.
    PIN Secure Code 22 is a PIN associated with a card registered in the MasterCard SecureCode system. It is considered here that the SecureCode system can also use a password and / or code, instead of a PIN.
    PIN ontine 24 is used in an online PIN verification process whereby the wallet application 12 plays the role of a “virtual terminal”, interacting to encrypt the PIN for transmission to the merchant. The use of an online PIN verification process can provide greater flexibility in authenticating transactions, for example, by allowing an issuing bank to authenticate transactions associated with its cardholders without the need for the issuing bank to register its cardholders and / or adopts new infrastructure.
    Users can have different instances of wallet application 12 on different phones. A sinc service. can keep multiple instances in sync with an online server (similar to how browser bookmarks can be stored offline in different instances of an internet browser and be synchronized across multiple machines.) Marketers can add a piece of code to their button debugging that invokes the wallet application. During debugging, users select the card and shipping address (if necessary). The authentication PIN is entered on the phone in response to a prompt from the mobile application. The wallet passes the information back to the merchant who submits that information through existing channels (internet gateway or payment processor), that is, no changes are required in existing processes or integration.
    In a preferred embodiment, the wallet application can be an HTML 5 browser application (not a native application) that self-installs on the mobile phone or computer browser on first use.
    In another preferred mode, the wallet application can securely store information on the phone (shipping address, changed card name, secure token, etc.) that information can be used to authenticate to the remote server. This also allows offline transactions. The mobile app can preferably “chat” as a secure element on the phone. In this regard, the mobile application can play the role of a virtual POS terminal in initiating CHIP transactions plus PIN present on a card.
    According to the present invention, a consumer can use his phone or computer to buy from a retailer based on the network. When the consumer is ready for debugging, he will preferably have the option to click on one: debug button associated with the present system. Clicking the button prompts the consumer to provide their username and password to register, and to confirm both the payment card to be used and the shipping address to which the item is to be sent. Subsequently, the system will prompt the consumer to enter the authentication PIN, and the transaction is then completed. At that point, the consumer is preferably returned to the merchant's website. The present invention provides several benefits for the consumer. More particularly, the present invention provides easy and convenient debugging through a form fill or pass function, which is preferably part of the wallet application. The present invention offers secure payments via PIN, or other biometric parameters such as voice or fingerprint. In this regard, the smart phone can be equipped with a biometric reader and / or analyzer. The present invention also provides benefits to the merchant including a - change of potential merchant liability to the authorization bank for all portfolio-based transactions. More particularly, the use of an authentication process for remote transactions reduces the risk of fraud associated with such transactions, and can limit / reverse the change in fraud liability from the authorization bank to the merchant. Using the authentication process described here can also - provide more attractive savings for the merchant through access to lower rate structures, depending on the consumer's authentication method. The present invention also provides limited integration impact in that it provides a simple wallet API for passing card details, shipping information and security tokens, and does not require any new contractual relationship (ie, leverages existing card acceptance). Finally, the present invention is backwards compatible (that is, it provides native support for SecureCode) thereby resulting in better ergonomics / consumer experience.
    The portfolio application of the present invention provides a comprehensive solution for financial transactions carried out through multiple channels of commerce. The present wallet application provides a winning and simple proposition for consumers, and provides an option of filling out a form in an innovative application. The present invention can use existing payment networks (eg Mastercard system worldwide) that are already accepted by merchants, thereby eliminating the need for heavy integration, while providing more security and better savings. The present invention does not require issuing banks to implement new requirements since the system can work with existing authorization techniques, for example, SecureCode, CHIP and PIN and / or PIN online. The present invention also considers the long-term convergence path of the three commercial platforms - retail, e-commerce and mobile - towards a centralized mobile phone system. The present is. invention also provides the potential to provide incremental top line revenue growth by 1) protecting transaction and revenue volumes; 2) for providing a - proprietary and innovative approach with the option of differently priced services for issuers, merchants or associates (eg, directory service, wallet service, etc.); and 3) for providing flexibility for further expansion (new source of funds, insurance elements, etc.).
    It is also considered that the authentication processes described here can be used in applications where the consumer has a “mute phone”. For example, in applications where the consumer is conducting an e-commerce transaction through his computer, or initiated a call to a call center, and the consumer does not have a smart phone, the present system can use existing or other SMS messages messaging technology to contact the consumer's “dumb phone” and request a PIN. After receiving the PIN from the “dumb phone”, the transaction can be authenticated and completed.
    Figure 2 is a flowchart representing the wallet application of the present invention being used in an e-commerce transaction (for example, a computer-initiated transaction) with a secure element and an offline PIN. In step 100, the consumer selects the “wallet” icon on the merchant's website. The wallet application is - then opened in step 102 by the browser on the user's computer. The consumer then registers with the wallet application (step 104). The appropriate payment card and shipping details are selected (step 106), and the PAN of the card is then sent to the ace wallet server (step 108). In step 110, the wallet server requests the Card Verification Method (CVM) from the MasterCard directory.
    This directory can be. based on an expanded version of the currently existing SecureCode directory, or it can be an entirely new directory.
    The appropriate CVM is confirmed in step 112. The wallet server then initiates the CVM check (step 114). A message to enter the PIN is then required on the browser (step 116) and on the mobile phone (step 118). The consumer then enters the offline PIN on the mobile phone in step 120. In step 122, the offline PIN is verified by the secure element on the phone.
    An “OK” message is displayed on the rn (step 124), and the ARQC is transmitted to the wallet server (step 126). The n: - -nvado (step 128), the authentication result is transmitted to the Mas ... Card directory (step 130), and the authorization data is transmitted to the browser (step 132). The transaction is then authorized by the merchant at step 134, and approval is displayed at step 136, resulting in a happy consumer (step 138). - 3 is a flowchart that represents the current application's wallet application, "used in an e-commerce transaction (for example, a computer-initiated transaction) with a SecureCode PIN.
    In step 200, the consumer selects the Ss “wallet” icon on the merchant's website.
    The wallet application is then opened at step 202 egador on the user's computer.
    The consumer then registers with the wallet application (step 204). The appropriate payment card and shipping details are selected (step 206), and the PAN of the card is then sent to the wallet server (step 208). In step 210, the wallet server requests the Card Verification Method (CVM) from the MasterCard directory.
    This directory can be based on an expanded version of the currently existing SecureCode directory, or it can be an entirely new directory.
    The appropriate CVM is confirmed in step 212. The wallet server then initiates the SecureCode authentication process (step 214). A “check phone” message is then displayed on the computer's browser (step 216) and a message to enter the SecureCode PIN is displayed on the mobile phone (step 218). The consumer then enters the SecureCode PIN on the mobile phone at step 220. In step 222, the wallet server packages the SecureCode for validation.
    SecureCode is then verified in step 224. - This verification process will be discussed in more detail below.
    After verification, an AAV is sent to the wallet server (step 226). An “OK” message is displayed on the browser (step 228) and on the phone (step 230). The authentication result is transmitted to the MasterCard directory (step 232), and the authorization data (step 234) is transmitted to the merchant for authorization (step 236). The transaction is then authorized in step 238, and approval is displayed in step 240, resulting in a happy consumer (step 242). Figure 4 is a flowchart that represents the portfolio application of this
    * invention being used in an e-commerce transaction (for example, a transaction initiated by telephone) with an online PIN. In step 300, the consumer selects the Icon ft “wallet” on the merchant's website. The consumer then selects the wallet application (step 302), which then displays a registration form (step 304). Alternatively, the —cart can be auto-detected. The consumer logs in step 306, sees the cards listed in step 308, and then selects the appropriate payment card and shipping details (step 310). In step 312, the wallet asks if an online PIN is associated with the card. The existence of the online PIN is confirmed in step 314. In step 316, the wallet requests entry of the online PIN on the phone. The online PIN is entered in step 318. Subsequently, the online PIN is encrypted (step 320), and issued to the merchant for authorization (step 322). The transaction is validated in step 324, the payment is approved in step 326, resulting in a happy consumer (step 328). Figure 5 is a flowchart representing the wallet application of the present invention being used in an e-commerce transaction (for example, a transaction initiated by telephone) without a secure element on the phone, without a SecureCode, and without an online PIN. In step 400, the consumer selects the “wallet” icon on the merchant's website. BR The consumer then selects the wallet application (step 402), which then displays a registration form (step 404). Alternatively, the portfolio can be self-detected. o: consumer logs in step 406, sees the cards listed in step 408, and then selects the appropriate payment card and shipping details (step 410). In step 412, the wallet asks if a SecureCode is associated with the card. The card is determined not to be in the SecureCode directory at step 414. The authorized data is then passed on to the wallet at step 416, which sends such data to the merchant for authorization (step 418). The transaction is validated in step 420, the payment is approved in step 422, resulting in a happy consumer (step 424). In this type of scenario, the issuing bank can accept or deny the transaction according to its existing standards. For example, the issuing bank may establish protocols whereby certain e-commerce and / or remote transactions are not approved in the absence of a successful authentication process.
    An existing 3D Secure process is shown in the flowchart in Figure 6. More particularly, the existing 3D Secure process includes step 501 whereby a merchant initiates an authentication request, and hisses the plug-in merchant (MP!) With the financial instrument information from the cardholder. It should be understood that the cardholder has already accessed the merchant's network page, and has indicated his desire to —acquire a specific product using a specific payment card. In step 502, MPI identifies the appropriate card type, and sends an authentication request (VEReg) to the relevant directory server. In step 503, the directory server
    Identifies the appropriate access control server (ACS), and requests an authentication response. In step 504, the ACS identifies the card and cardholder, and sends a & reply (VERes) with authentication prompts at the ACS URL. In step 505, the directory server sends the authentication response (with the ACS URL) to MPI. In step 506, the —MPI sends the payment authentication request (PARegq) to the merchant for display during debugging. The payment authentication request includes the ACS URL. In step 507, the payment authentication request is sent from the merchant to the ACS - in other words, the merchant calls the ACS URL. In step 508, ACS sends a pop-up window to the merchant that appears in the cardholder's browser asking the cardholder to enter the authentication credential. In step 509, the cardholder enters the requested authentication credentials, and such information is sent back to the ACS for authentication. In step 510, the ACS validates the authentication credentials, and if correct, sends an AAV confirming authentication to the merchant.
    Thereafter, the merchant proceeds to authorize the transaction in the usual manner. 1 A disadvantage of the process described above with respect to figure 6 is that the authentication process requires the use of a pop-up window that appears during the online transaction process. Many online shoppers have been taught to be suspicious of pop-up windows, and are reluctant to enter relevant financial information into that window - for fear that the pop-up window may come from a fraudulent website and / or be part of a phishing scam .
    The new modalities of the present invention shown in figures 7 and 8 not only address the disadvantages of confirming in pop-up windows during authentication, but also provide the merchant with better control over the debugging experience presented to their customers. These new processes are shown in the context of a phone with a wallet application. However, it should be understood here that these processes can also be used in conventional cardholder merchant / browser transactions, that is, a transaction carried out without a phone and / or wallet application.
    Returning first to figure 7, the wallet detects the clearance page and makes a payment request (step 601). The wallet then authenticates the user, at which point the user can select the payment type (step 602). The wallet server then determines which branded 3DS Directory to use based on the selected account number (step 603). The user's participation is then verified (step 604). The wallet then retrieves the SecureCode (step 605). In particular, the user is prompted to log in - his SecureCode with part of the wallet subscription or as a separate prompt (step 605a) and / or the wallet retrieves / generates the user's SecureCode that was safely stored on the wallet and phone server ( step 605b). SecureCode is then sent
    * to the bank for verification (step 606). The wallet form then fills in the payment details, including the AAV, on the merchant's page (step 607). the 7 merchant then authorizes the transaction in normal mode (step 608), and receives the necessary approval (step 609).
    Turning now to Figure 8, the process includes a step 701 in which the merchant initiates a transaction request. It should be understood that the merchant has already integrated his existing payment system with the wallet application in such a way that the merchant can receive authentication information from the wallet. In step 702, the wallet initiates an authentication request, and hisses the MasterCard Plug-in Merchant (MC-MPI) formed in accordance with the present invention with the cardholder's financial instrument information. In step 703, the MC-MPI identifies the appropriate card type, and sends a request to verify registration (VEReg) to the relevant directory server. In step 704, the directory server identifies the appropriate ACS, and sends the registration verification request (VEReq), waiting for a registration verification response (VERes). In step 705, the ACS identifies the card and cardholder, and sends a response (VERes) with the ACS URL. In step 706, the directory server sends the response (VERes Sã 7S URL) to MC-MPI |. At that point, instead of MC-MPI communicating back with O api. 2 portfolio, the MC-MPI communicates directly with the ACS. More particularly, - in step 707, the MC-MP! sends a payer authentication request (PARegq) to the ACS. In other words, MC-MPI formats the expected request and calls the ACS URL.
    In step 708, ACS responds with traditional browser HTML markup for MC-MPI. In step 709, the MC-MPI then interprets the HTML markup, including the authentication criteria, and extracts the necessary elements from the HTML markup and translates it into the API protocol that is then communicated to the wallet. The wallet then displays an authentication request to the cardholder, asking the cardholder to enter their authentication credentials. In step 710, the wallet communicates the cardholder's authentication credentials to MC-MP! through API protocol. In step 711, the MC-MP! translates cardholder authentication credentials in the format expected by the ACS and uses an HTTP POST to communicate the credentials to the ACS. In step 712, the ACS validates the authentication credentials, and sends a payer authentication response (PARes including AAV) back to the MC-MPI representing the authentication result. In step 713, the MC-MPI passes the AAV and information received from the ACS to the wallet through the API protocol. In step 714, the wallet passes the AAV and authentication message to the merchant through the API protocol. The merchant then proceeds to authorize the transaction in the usual manner.
    As described, in step 708 of figure 8, the ACS sends the authentication criteria to the MC-MPI for translation. In other words, instead of sending the HTML markup
    It is served by the ACS directly back to the wallet application, the information needed for authentication is sent to the MC-MPI via HTML markup, "which can then translate that information and send it in a predetermined way.
    More particularly, with respect to a wallet application, such an application could be designed to communicate with the MC-MPI in a knowledgeable and consistent manner so that a consumer does not receive a “suspicious” pop-up window. Instead, the wallet app can cooperate with The MC-MP! such that every authentication transaction is carried out in a recognized window.
    As mentioned above, the processes described in figures 7 and 8 are also applicable to non-portfolio-based transactions.
    More particularly, browser-based transactions using a 3D Secure process, or other similar process, sending a pop-up window from the ACS directly back to the merchant can introduce uncertainty into the authentication process.
    Therefore, the MC-MPI shown in figure 8 could, in another application, communicate directly with a cardholder merchant / browser in the absence of a phone.
    Such an arrangement could allow The merchant to control how the authentication request appears to the customer during the debugging process.
    In other words, for sending the authentication criteria through MC-MP! (where it is translated), the translation information can be sent back. to the merchant's network page in a predetermined and selected mode, thereby giving the merchant greater control over their customers' shopping experience - while also eliminating the use of pop-up windows.
    In another modality, the wallet is used as a security supplement.
    In an application, this is accomplished by authenticating the wallet itself.
    More particularly, the wallet application is loaded onto the phone, and a payment card is entered into the - application.
    The user's identity is verified, and the wallet subsequently retains payment data in a secure mode.
    When the user subsequently uses the wallet to make a purchase, the wallet can communicate to the merchant that the wallet itself has been authenticated, thereby decreasing the likelihood of a fraudulent transaction.
    With reference to figure 9A, the SecureCode process can be used to authenticate a wallet.
    In this regard, the user signs the wallet and registers a card (step 800). The SecureCode process is started for authentication (step 801). The 3SA directory is then accessed in step 802. The user is then prompted for SecureCode (step 803). SecureCode is verified by the ACS (step 804). If authenticated, the payment card is accepted and stored in the wallet in a secure mode (step 805). Of course, - it is considered here that another process could be used to authenticate the wallet, such as an online PIN or an exclusive wallet code / PIN provided by the issuing bank.
    During a future transaction, the wallet can communicate to the merchant that the
    : card was previously authenticated, thereby reducing the likelihood of a fraudulent transaction.
    Turning now to Figure 9B, the process shown is similar to that shown in Figure 7 with the exception of step 810. After the user signs the wallet, the wallet can determine whether to seek additional authentication from the user.
    For example, for certain transactions (for example, a transaction that exceeds a specific monetary value, a transaction outside the user's normal spending habits, etc.) the issuing bank may require authentication in addition to wallet authentication.
    Thus, if additional authentication is required, the wallet will initiate the SecureCode process.
    If additional authentication is not required, the wallet will bypass the SecureCode process and proceed with the transaction.
    Of course, it is considered here that the subsequent authentication process may be different from the SecureCode process, for example, an online PIN.
    In another preferred embodiment, a portfolio MPI is considered to be where the portfolio becomes the new MPI SecureCode for merchants.
    With reference to figure 10, the wallet detects clearance at the merchant in step 901. The wallet then authenticates the user (step 902) and payment details are selected (step 902). The wallet server then determines that the bank is the wallet's ACS client, and that no further authentication is required (step 803). The rest of the process is the same as - shown in figure 7. It should be noted that the process shown in figure 10 does not require theMPIeoaACS shown and described in figure 7. This way, this modality can provide a simple way for merchants to implement the SecureCode process without the need for investment in infrastructure by both the merchant and the issuing bank.
    It will be recognized that the present invention has been described here with reference to certain - preferred or exemplary embodiments.
    The preferred or exemplary modalities described here can be modified, altered, added or diverted from without departing from the intention, spirit and scope of the present invention, and it is intended that all such additions, modifications, changes and / or deviations are included in the scope of the present invention.
    权利要求:
    Claims (1)
    [1]
    1. Method for removing pop-up windows during an authentication process involving a cardholder using an electronic transaction payment card, CHARACTERIZED for understanding the steps of: sending authentication criteria directly from an account control server access to a plug-in merchant; translate said authentication criteria into a language compatible with the said plug-in merchant; forward said authentication criteria through the plug-in merchant to a device operated by said cardholder for the entry of authentication credentials associated with the payment card, in the absence of a pop-up window.
    2. Method, according to claim 1, CHARACTERIZED by the fact that the aforementioned authentication criteria are transmitted in HTML markup, and in which the method further comprises the step of translating the HTML markup into the programming interface protocol application. It is 3. Method, according to claim 2, CHARACTERIZED because it also includes the step of resuming authentication credentials through the plug-in merchant for said access control server for the validation of said credentials.
    4. Method, according to claim 3, CHARACTERIZED because it also includes the step of translating the authentication credentials received by said plug-in merchant from said application programming interface protocol to said HTML markup.
    5. Method, according to claim 4, CHARACTERIZED by further comprising the step of sending a validation response from said access control server to said plug-in merchant for later transmission to a merchant participating in said electronic transaction.
    6. Method for authenticating the identity of a cardholder during an electronic transaction that involves a payment card using secure 3D protocols, CHARACTERIZED for understanding the steps of: a) sending a verification registration request to a directory server; b) identify an access control server associated with said card; c) sending a verification registration response from said access control server to said directory registration server, said verification registration response, including a URL address of said access control server; d) send the verification registration response to a plug-in merchant associated with a merchant involved in the said electronic transaction; e) send a payment authentication request from said plug-in merchant to the
    It is: 268 said access control server; f) send an HTML markup browser from said access control server to said plug-in merchant; g) extract data from the HTML markup associated with said authentication of said card; h) transmit extracted data to a wallet application associated with the cardholder for the entry of authentication credentials; i) send credentials for the application of the wallet through said plug-in merchant to said access control server; j) send translated credentials from the plug-in merchant to said access control server for validation; k) transmit, by means of credentials validation, a payer authentication response and a payment authorization from said access control server to said plug-in merchant; 1) transmit the plug-in merchant's authorization for wallet application for later transmission to said merchant. &. 7. Method, according to claim 8, CHARACTERIZED by the fact that said extraction step also includes the steps of interpreting HTML markup.
    8. Method, according to claim 6, CHARACTERIZED because it further comprises the step of translating said extracted data into the application programming interface protocol.
    9. Method, according to claim 6, CHARACTERIZED by the fact that said authentication credentials are sent from the said wallet application to said plug-in merchant through the application of a programming interface protocol.
    10. Method, according to claim 6, CHARACTERIZED by further comprising the step of submitting an application for said cardholder to introduce authentication credentials on said cardholder phone.
    11. Method, according to claim 6, CHARACTERIZED by further comprising the step of converting the credentials received from said wallet application to an appropriate format for reception by said access control server.
    12. Method, according to claim 11, CHARACTERIZED because it further comprises the step of translating the credentials of said application programming interface protocol to said HTML markup
    13. Method of reducing fraudulent transactions associated with e-commerce, FEATURED for understanding the steps of: providing a wallet application for storage on a cell phone
    home; enter data associated with a payment card for said wallet application; authenticate the cardholder identity associated with said payment card through an authentication process; placing said wallet application in an authenticated state in which the data associated with said payment card is securely stored within said wallet application; communicate the authenticated status of the wallet, said to a merchant during said electronic translation.
    14. Method, according to claim 13, CHARACTERIZED because it also comprises the steps of: analyzing said financial transaction to assign a risk factor for the transaction; determine whether authentication is required based on said designated risk factor.
    : 15. System to authenticate the identity of a cardholder during an electronic transaction, involving a payment card enrolled in an authentication program, CHARACTERIZED for understanding: a directory server to verify the registration of said card in said program; a communication access control server with said directory server, the access control server, containing the authentication credentials associated with said card, a plug-in merchant in communication with the directory server and as a control server access, and in which said plug-in merchant is able to receive authentication criteria directly from said access control server and is also able to translate said criteria into a language that allows transmission of the said criteria, by means of the plug-in merchant for an electronic device associated with the aforementioned cardholder.
    16. System, according to claim 15, CHARACTERIZED by the fact that said plug-in merchant includes a translator for extracting data from said authentication criteria received from said access control server.
    17. System, according to claim 15, CHARACTERIZED by understanding — still a mobile phone and a wallet application, said application being stored on said phone and adapted to receive said authentication criteria from said plug-in merchant in for the subsequent entry of said validation credentials.
    R ã o | 8 SN ê Ê o - e z: ê ds u 2 8 $ + 8 338 Í 5 gives É 2)) à! S :
    7th% 3: | S - EH
    E ts
    ME E 3 * | : Ê |
    DT and S5e sed S | [888 $ to E, ES | and ds ”| E: If E 1 & fe | To El E | | q I was going to
    DEE; S consumer navigator Wallet server 2PÍSAAO, diameter of -
    | "O a A!: Be at 38º 2 MNãsses 3 * ê - Ss 38 88 NI nn x ne 1. Cl ace: N. Es: Negras |. 7 $ | <Ex SNS ts jul Sã | Í S áporspssiopítias - O si | "si | erhicies ae re Fo E) 2 “s | & healthy. & | 1 Ho $ ES | 5523 '465 | healthy 2 HH | 7 x - Y S S »| : = 33% and Hits pe A: 58 Eãe 228: ESSO Ss O 2 335 883 Ss - T e 3º | | : £ at a) Es | Ns 25
    PE consumer browser * Bite application - merchant directory - issuer year <| ——: | Ú à à at 3 A Ss 8 - 28 3 e d157 8 Te $ 1: - = A $ o ti 2: + ã 82 | ã O: 3 | 7; Es F E aee Í =; : º 28:
    AND IS . 2 s $ Ns Ds Ê à e O | 8 3 As dh, | $ - DE
    88. A. 3835 S no 8 3: $ 6 3 You are 2 N 4 ds Are 288 2uhs 3rd and are healthy 57 gis:. At $ 88 &
    And the tt, ss me] the Slug ds | tt consumed Srs, Abd emesor trader
    | NR ia = A õ a MUS> a à ——- Sã Ugo | 2 | wing and med AB | “1 A) and Y SR j Ne | E: IX. 35% = GS - - and KW AND MO. $$. / NA 833: 2883 '[DA | $ HM ê 6 ss É / ss a l Nat À il vs SB -: fm E ão. 84 | 2 fo. 2Rs CI) Foo. + £ 2 E [1 E: [E Eno oaTENA, INES emo love
    7 AAV-3D Secure Account authentication value CH = cardholder EReg = request to verify records VERes = response to verify registration 1 = request icaçã teinavegade s1o PARA = authentication request | (uiiiar paço / PARes = authentication / payer response and REaT cane 500 | - i SM lAES E V ETR) MES 507 o i 501 E:] 1 o. i information from “Our through | Éio Di debugging - DIR ecommerce browser - card holder 1 Ss 8 1: E: 506 E E i: so | | redirect q 1 | ass. & OD 8 | jeomerciante x à.
    VEReq q à: | | PAIRS VERES i | with AAV with io ACS URL io 505 5 504 Qro VERes E 0 (Q VERAa 503 Implementation of existing 3D Secure F | G 6
    - EE; ê ENS à - 3 already ê 2 ds a so add E su | t + Yo BS | / Í ês 3 ó & à É o | Ss * 'S S8 o e, s5 | What if $ ES Sto E: + 388 e
    HE HS 7 ê: É 3 | s8 i; 8.! ; and 3 are: im css] Ê o Wo & 7 if É ê at 382 RS OX 8 o as: S 8 is Ss 88 tê: 21 | ; E: il «is the õ o É Ê SE 3 à dE |. 3 | is ss IS MM 3 | 8 | . o ê O ê $ Ta À "o o
    The integration “Tite” E> Tu S Ns 3 AAV Resu1 702 & 710 - AAV-3D Secure Value of 88 x account authentication 48 s õ ã õ CH = cardholder E 2 EE EReq = request to verify records! FF IS FS VERes = register verification response: it is 3 3 PAReq = payer authentication request PARes = authentication answer 709 718 a payer:: 703 "> LE.
    VEReq Mr sense Ss VERes 8 is: ACS URL = 2 to E 706 707 Pros: 712 directory server | 705 Ç VERES EA Wo Sm VM VEReq MPI concept from MasterCard
    1 gal 2 2 3 Sds Z ls; $ s5It's 3 3885 3 | 83º $ 385 at: | and ES O that al: o, EE as S: 8 and | And RO Ê r «38: e $ É. : 8 3 5 & & Ss j 3 í FR * z F - Ti 2 à dm à às are 5 Í - 3 Si $ o wa: 3 N o
    + H sê ae -: CH go] ug [o (s *. É 26 36 Fe Em s8 s F & sô: ã Se. Í ê '3 TN js 78 e ss 3 e la:: E [EB O & ê = 82% | - 2E â e ses = 8 í 7 ú Í E | 53. As% Ê E |: && é:: ss $ "gj 4 3 Fe 8 In 3 $ à: $ * $ i 2588 LEA 8 o Sdss o 8 CE) Ls IF F ã ê $ 382 É ã £ $ o AND É É ê 257 a: 58) ã o
    8th TR = & EIA TN As Ss> à> $$ 85 â É ss Hs 3 $ eo É mec É s% s dl 3 É ils 3 $ H 8 8 288 552 be 5 at O.: 25 Te í 8 :
    ER E j ds F g884 z Es) j SOS | + 35 | EF E z ê ê E 33º ã E j 3 3 Es $ - = as 3 8 8 z 23 3 ES) Bo Ss 3
    类似技术:
    公开号 | 公开日 | 专利标题
    US10460319B2|2019-10-29|Multi-commerce channel wallet for authenticated transactions
    US20180240115A1|2018-08-23|Methods and systems for payments assurance
    KR101015341B1|2011-02-16|Online payer authentication service
    US20080189209A1|2008-08-07|Real-Time Funds Transfer
    US10956899B2|2021-03-23|Mechanism to allow the use of disposable cards on a system designed to accept cards conforming to the standards of the global payments industry
    CA2823321A1|2012-07-05|Mobile payment system and method
    US20170024738A1|2017-01-26|System and method for electronic payment using payment server provided transaction link codes
    JP2016076262A|2016-05-12|Method of paying for product or service in commercial website via internet connection and corresponding terminal
    AU2017206035B2|2020-03-05|Authenticating payment credentials in closed loop transaction processing
    EP3811313A1|2021-04-28|Systems and methods for processing purchase transactions using a mobile device
    EP3712828A1|2020-09-23|Payment token mechanism
    Fashoto et al.2016|Development of e-wallet system for Tertiary institution in a Developing country
    KR20090001877A|2009-01-09|System and method for processing anticipation by using payment guarantees and program recording medium
    KR20090075785A|2009-07-09|Devices for payment settlement using ic card
    KR20090002007A|2009-01-09|System and method for payment settlement using ic card and program recording medium
    KR100876589B1|2008-12-31|Point processing method and system according to fund subscription and recording medium therefor
    KR20090000804A|2009-01-08|System and method for managing community account and program recording medium
    KR20080037750A|2008-05-02|System and method for processing information and program recording medium
    KR20080022888A|2008-03-12|Method and system for affilating financial agency and shopping mall and program recording medium
    同族专利:
    公开号 | 公开日
    US20160078428A1|2016-03-17|
    CA2823685A1|2012-02-16|
    CA2958140C|2019-05-07|
    AU2015213354A1|2015-09-03|
    IL224685A|2017-04-30|
    EP2603892A4|2015-09-02|
    CA2915867A1|2012-02-16|
    SG187832A1|2013-03-28|
    AU2011289180B2|2015-05-28|
    US20120143752A1|2012-06-07|
    AU2015315602A1|2017-04-06|
    US20170243218A1|2017-08-24|
    WO2012021864A2|2012-02-16|
    WO2012021864A3|2012-04-19|
    SG10201506319WA|2015-09-29|
    US20170243219A1|2017-08-24|
    CA2915867C|2018-03-13|
    EP2603892A2|2013-06-19|
    CA2958140A1|2012-02-16|
    CA2823685C|2017-03-07|
    US10769632B2|2020-09-08|
    US10460319B2|2019-10-29|
    AU2015213354B2|2017-03-16|
    AU2011289180A1|2013-03-14|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US5696909A|1995-01-27|1997-12-09|Hypercom, Inc.|Virtual POS terminal|
    US7343351B1|1999-08-31|2008-03-11|American Express Travel Related Services Company, Inc.|Methods and apparatus for conducting electronic transactions|
    KR101015341B1|2000-04-24|2011-02-16|비자 인터내셔날 써비스 어쏘시에이션|Online payer authentication service|
    US20020179704A1|2001-06-05|2002-12-05|Ncr Corporation|Enhanced digital wallet|
    US7111789B2|2001-08-31|2006-09-26|Arcot Systems, Inc.|Enhancements to multi-party authentication and other protocols|
    US20030074660A1|2001-10-12|2003-04-17|Liberate Technologies|System method and apparatus for portable digital identity|
    US7904360B2|2002-02-04|2011-03-08|Alexander William EVANS|System and method for verification, authentication, and notification of a transaction|
    US20030195963A1|2002-04-10|2003-10-16|Yu Song|Session preservation and migration among different browsers on different devices|
    US7707120B2|2002-04-17|2010-04-27|Visa International Service Association|Mobile account authentication service|
    US7693783B2|2002-06-12|2010-04-06|Cardinalcommerce Corporation|Universal merchant platform for payment authentication|
    ES2659723T3|2002-06-12|2018-03-19|Cardinalcommerce Corporation|Universal merchant platform for payment authentication|
    US20040210536A1|2002-12-18|2004-10-21|Tino Gudelj|Cross-domain transactions through simulated pop-ups|
    US7360694B2|2003-01-23|2008-04-22|Mastercard International Incorporated|System and method for secure telephone and computer transactions using voice authentication|
    US20050289052A1|2003-01-23|2005-12-29|John Wankmueller|System and method for secure telephone and computer transactions|
    ES2581236T3|2003-06-10|2016-09-02|Mastercard International, Inc.|Systems and methods that allow secure payment transactions using a formatted data structure|
    BRPI0411005A|2003-06-04|2006-07-04|Mastercard International Inc|systems for authentication of a customer business transaction and method for remote authentication of a customer participating in an electronic business transaction using the network access device|
    EP1492068A3|2003-06-24|2009-08-05|LG TeleCom, Ltd.|Method for providing banking services by use of mobile communication system|
    US7653602B2|2003-11-06|2010-01-26|Visa U.S.A. Inc.|Centralized electronic commerce card transactions|
    US7039611B2|2003-11-06|2006-05-02|Visa U.S.A., Inc.|Managing attempts to initiate authentication of electronic commerce card transactions|
    KR20050045157A|2003-11-10|2005-05-17|소프트포럼 주식회사|Electronic payment system and method thereof|
    WO2005053345A1|2003-11-25|2005-06-09|Xius India Ltd.|Method and system for accessing wireless networks|
    US20050222961A1|2004-04-05|2005-10-06|Philippe Staib|System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device|
    US20050246649A1|2004-04-29|2005-11-03|Wilhelm Gerita S|Online/offline multimedia directory system|
    US8762283B2|2004-05-03|2014-06-24|Visa International Service Association|Multiple party benefit from an online authentication service|
    KR100930457B1|2004-08-25|2009-12-08|에스케이 텔레콤주식회사|Authentication and payment system and method using mobile communication terminal|
    WO2006102270A2|2005-03-22|2006-09-28|Cooper Kim A|Performance motivation systems and methods for contact centers|
    US7540408B2|2006-06-22|2009-06-02|Hip Consult Inc.|Apparatus and method for facilitating money or value transfer|
    EP1965343A3|2006-07-06|2011-03-02|Firethorn Holdings, LLC|Methods and systems for payment method selection by a payee in a mobile environment|
    US7761380B2|2006-09-28|2010-07-20|Verifi, Inc.|System and method for authenticating a payment instrument transaction originating from a non-internet channel|
    US10346837B2|2006-11-16|2019-07-09|Visa U.S.A. Inc.|Adaptive authentication options|
    US7720783B2|2007-03-28|2010-05-18|Palo Alto Research Center Incorporated|Method and system for detecting undesired inferences from documents|
    KR101540417B1|2007-04-17|2015-07-29|비자 유에스에이 인코포레이티드|Method and system for authenticating a party to a transaction|
    KR20090012897A|2007-07-31|2009-02-04|주식회사 퍼스트포켓|Method and system for providing financial service by using electronic wallet apparatus, integration electronic wallet server, electronic wallet supportive terminal|
    US7707113B1|2007-09-28|2010-04-27|Sprint Communications Company L.P.|Method and system for setting levels of electronic wallet security|
    WO2009076073A2|2007-12-05|2009-06-18|Google Inc.|On-line payment transactions|
    US20090216840A1|2008-02-21|2009-08-27|Nokia Corporation|Method for providing services to user interfaces|
    US20090234751A1|2008-03-14|2009-09-17|Eric Chan|Electronic wallet for a wireless mobile device|
    US9208485B2|2008-03-24|2015-12-08|American Express Travel Related Services Company, Inc.|System and method for facilitating online transactions|
    US8639600B2|2008-08-11|2014-01-28|Visa U.S.A. Inc.|Mobile payer authentication|
    CA2985938C|2008-08-27|2020-01-07|Cardinalcommerce Corporation|Intelligent server routing of payment instruments|
    US8612305B2|2008-10-31|2013-12-17|Visa International Service Association|User enhanced authentication system for online purchases|
    GB2466810A|2009-01-08|2010-07-14|Visa Europe Ltd|Processing payment authorisation requests|
    KR20100084068A|2009-01-15|2010-07-23|정태우|System and method for online commerce|
    US8261977B2|2009-03-27|2012-09-11|Mastercard International Incorporated|Methods and systems for using an interface and protocol extensions to perform a financial transaction|
    WO2010111661A1|2009-03-27|2010-09-30|Mastercard International Incorporated|Methods and systems for performing a financial transaction|
    RU2012122806A|2009-11-04|2013-12-10|Виза Интернэшнл Сервис Ассосиэйшн|CHECKING THE AUTHENTICITY OF PORTABLE HOUSEHOLD DEVICES FOR IMPLEMENTING PRINCIPLES OF THREE-DOMAIN PROTECTION OF SERVICES|
    US20100312703A1|2009-06-03|2010-12-09|Ashish Kulpati|System and method for providing authentication for card not present transactions using mobile device|
    TW201104603A|2009-07-31|2011-02-01|Hsinchu Transp Co Ltd|Information processing system, processing station, and the method to pay by credit card on arrival of goods|
    US8527417B2|2010-07-12|2013-09-03|Mastercard International Incorporated|Methods and systems for authenticating an identity of a payer in a financial transaction|
    US8468545B2|2010-08-18|2013-06-18|8X8, Inc.|Interaction management|US7508946B2|2001-06-27|2009-03-24|Sony Corporation|Integrated circuit device, information processing apparatus, memory management method for information storage device, mobile terminal apparatus, semiconductor integrated circuit device, and communication method using mobile terminal apparatus|
    US10867298B1|2008-10-31|2020-12-15|Wells Fargo Bank, N.A.|Payment vehicle with on and off function|
    US20100114768A1|2008-10-31|2010-05-06|Wachovia Corporation|Payment vehicle with on and off function|
    CA2960704C|2014-09-12|2019-05-07|Mastercard International Incorporated|Pairing electronic wallet with specified merchants|
    US20130212012A1|2010-10-15|2013-08-15|34 Solutions, Llc|System And Method For Mobile Electronic Purchasing|
    US20120095865A1|2010-10-15|2012-04-19|Ezpayy, Inc.|System And Method For Mobile Electronic Purchasing|
    GB201105765D0|2011-04-05|2011-05-18|Visa Europe Ltd|Payment system|
    CN102769846A|2011-05-04|2012-11-07|中国银联股份有限公司|User terminal and payment system|
    US8412631B2|2011-05-13|2013-04-02|American Express Travel Related Services Company, Inc.|Cloud enabled payment processing system and method|
    US8538845B2|2011-06-03|2013-09-17|Mozido, Llc|Monetary transaction system|
    US9208488B2|2011-11-21|2015-12-08|Mozido, Inc.|Using a mobile wallet infrastructure to support multiple mobile wallet providers|
    US10438196B2|2011-11-21|2019-10-08|Mozido, Inc.|Using a mobile wallet infrastructure to support multiple mobile wallet providers|
    BR112014017922A2|2012-01-19|2017-06-27|Mastercard International Inc|system and method for enabling a digital wallet network|
    US20130198066A1|2012-01-27|2013-08-01|Google Inc.|Fraud Protection for Online and NFC Purchases|
    US9767453B2|2012-02-23|2017-09-19|XRomb Inc.|System and method for processing payment during an electronic commerce transaction|
    US9092776B2|2012-03-15|2015-07-28|Qualcomm Incorporated|System and method for managing payment in transactions with a PCD|
    US9818098B2|2012-03-20|2017-11-14|First Data Corporation|Systems and methods for facilitating payments via a peer-to-peer protocol|
    US20130297509A1|2012-05-07|2013-11-07|Infosys Limited|Mobile payment using dynamic authorization code and multi-payer shared card number|
    US20130347075A1|2012-06-22|2013-12-26|Tyfone, Inc.|Method and apparatus for secure consolidation of cloud services|
    US20130346223A1|2012-06-26|2013-12-26|Rajen S. Prabhu|Processing point-of-sale transactions using a mobile card and mobile phone|
    AU2013315510B2|2012-09-11|2019-08-22|Visa International Service Association|Cloud-based Virtual Wallet NFC Apparatuses, methods and systems|
    US20140074704A1|2012-09-11|2014-03-13|Cashstar, Inc.|Systems, methods and devices for conducting transactions with electronic passbooks|
    US9092828B2|2012-09-19|2015-07-28|Mastercard International Incorporated Purchase|Data sharing platform|
    US10853890B2|2012-09-19|2020-12-01|Mastercard International Incorporated|Social media transaction visualization structure|
    US9082119B2|2012-10-17|2015-07-14|Royal Bank of Canada.|Virtualization and secure processing of data|
    US11222329B2|2012-11-05|2022-01-11|Mastercard International Incorporated|Electronic wallet apparatus, method, and computer program product|
    US8898769B2|2012-11-16|2014-11-25|At&T Intellectual Property I, Lp|Methods for provisioning universal integrated circuit cards|
    US8959331B2|2012-11-19|2015-02-17|At&T Intellectual Property I, Lp|Systems for provisioning universal integrated circuit cards|
    US9898734B2|2012-12-19|2018-02-20|Deutsche Telekom Ag|Method and system for terminal device-based communication between third-party applications and an electronic wallet|
    KR20140095745A|2013-01-25|2014-08-04|삼성전자주식회사|Supporting Method For Payment and System thereof|
    US9965756B2|2013-02-26|2018-05-08|Digimarc Corporation|Methods and arrangements for smartphone payments|
    US9830588B2|2013-02-26|2017-11-28|Digimarc Corporation|Methods and arrangements for smartphone payments|
    US9830202B1|2013-04-24|2017-11-28|Google Llc|Storage and process isolated web widgets|
    US10229400B2|2013-06-07|2019-03-12|Swoop Ip Holdings Llc|System and method for two-click validation|
    US20140365363A1|2013-06-07|2014-12-11|Prairie Cloudware, Inc|Secure integrative vault of consumer payment instruments for use in payment processing system and method|
    EP2824628A1|2013-07-10|2015-01-14|Vodafone Holding GmbH|Direct debit procedure|
    US9818101B2|2013-09-05|2017-11-14|Mastercard International Incorporated|System and method for socially connecting payment card holders|
    US9036820B2|2013-09-11|2015-05-19|At&T Intellectual Property I, Lp|System and methods for UICC-based secure communication|
    US9124573B2|2013-10-04|2015-09-01|At&T Intellectual Property I, Lp|Apparatus and method for managing use of secure tokens|
    US9208300B2|2013-10-23|2015-12-08|At&T Intellectual Property I, Lp|Apparatus and method for secure authentication of a communication device|
    US9240994B2|2013-10-28|2016-01-19|At&T Intellectual Property I, Lp|Apparatus and method for securely managing the accessibility to content and applications|
    US9313660B2|2013-11-01|2016-04-12|At&T Intellectual Property I, Lp|Apparatus and method for secure provisioning of a communication device|
    US9240989B2|2013-11-01|2016-01-19|At&T Intellectual Property I, Lp|Apparatus and method for secure over the air programming of a communication device|
    US9413759B2|2013-11-27|2016-08-09|At&T Intellectual Property I, Lp|Apparatus and method for secure delivery of data from a communication device|
    EP3078220A4|2013-12-02|2017-05-17|Mastercard International Incorporated|Method and system for secure tranmission of remote notification service messages to mobile devices without secure elements|
    AU2014357381B2|2013-12-02|2017-03-23|Mastercard International Incorporated|Method and system for secure authentication of user and mobile device without secure elements|
    SG11201604906QA|2013-12-19|2016-07-28|Visa Int Service Ass|Cloud-based transactions methods and systems|
    US9922322B2|2013-12-19|2018-03-20|Visa International Service Association|Cloud-based transactions with magnetic secure transmission|
    US9311639B2|2014-02-11|2016-04-12|Digimarc Corporation|Methods, apparatus and arrangements for device to device communication|
    CA2933336C|2014-04-14|2018-09-04|Mastercard International Incorporated|Method and system for generating an advanced storage key in a mobile device without secure elements|
    AU2015248458A1|2014-04-16|2016-12-01|Nucleus Software Exports Limited|Device, system and method for efficiently servicing high volume electronic transactions|
    US9713006B2|2014-05-01|2017-07-18|At&T Intellectual Property I, Lp|Apparatus and method for managing security domains for a universal integrated circuit card|
    WO2015179637A1|2014-05-21|2015-11-26|Visa International Service Association|Offline authentication|
    US9775029B2|2014-08-22|2017-09-26|Visa International Service Association|Embedding cloud-based functionalities in a communication device|
    US10657521B2|2014-09-16|2020-05-19|Mastercard International Incorporated|Systems and methods for determining fraudulent transactions using digital wallet data|
    SG10201406521TA|2014-10-10|2016-05-30|Mastercard Asia Pacific Pte Ltd|Methods and systems for secure online payment|
    WO2016068871A1|2014-10-28|2016-05-06|Total System Services, Inc.|Automated payment information update with vendors|
    US10187363B2|2014-12-31|2019-01-22|Visa International Service Association|Hybrid integration of software development kit with secure execution environment|
    CA2974151A1|2015-01-19|2016-07-28|Royal Bank Of Canada|Secure processing of electronic payments|
    US11080701B2|2015-07-02|2021-08-03|Royal Bank Of Canada|Secure processing of electronic payments|
    US10762496B2|2015-02-06|2020-09-01|Google Llc|Providing payment account information associated with a digital wallet account to a user at a merchant point of sale device|
    US10178088B2|2015-03-12|2019-01-08|Tejas Networks Ltd.|System and method for managing offline and online password based authentication|
    US11127009B2|2015-04-07|2021-09-21|Omnyway, Inc.|Methods and systems for using a mobile device to effect a secure electronic transaction|
    US10853773B2|2015-07-13|2020-12-01|Disney Enterprises, Inc.|Methods and systems for conducting multi-user interactions on a device using biometric authentication|
    US11170364B1|2015-07-31|2021-11-09|Wells Fargo Bank, N.A.|Connected payment card systems and methods|
    SG10201507756RA|2015-09-17|2017-04-27|Mastercard Asia Pacific Pte Ltd|Method of associating a customer's mobile computer device with an order for goods and/or services taken by a waiter in a merchant's venue|
    US11232453B2|2015-09-30|2022-01-25|Mastercard International Incorporated|Method and system for authentication data collection and reporting|
    RU2018117661A3|2015-10-15|2020-04-16|
    SG10201509891UA|2015-12-02|2017-07-28|Mastercard International Inc|Method And System For Providing A Digital Gift Card|
    KR20180099811A|2015-12-28|2018-09-05|모비웨이브 인코포레이티드|System and method for authenticating a user on a device|
    US10546289B1|2015-12-30|2020-01-28|Wells Fargo Bank, N.A.|Mobile wallets with automatic element selection|
    US11087304B2|2016-03-14|2021-08-10|Jpmorgan Chase Bank, N.A.|Systems and methods for device authentication|
    US10776785B2|2016-03-14|2020-09-15|Jpmorgan Chase Bank, N.A.|Systems and methods for device authentication|
    CA3013371A1|2016-03-22|2017-09-28|Visa International Service Association|Adaptable authentication processing|
    US10949822B2|2016-03-25|2021-03-16|Stripe Inc.|Methods and systems for providing payment interface services using a payment platform|
    US10902405B1|2016-05-11|2021-01-26|Wells Fargo Bank, N.A.|Transient mobile wallets|
    US10963589B1|2016-07-01|2021-03-30|Wells Fargo Bank, N.A.|Control tower for defining access permissions based on data type|
    US10992679B1|2016-07-01|2021-04-27|Wells Fargo Bank, N.A.|Access control tower|
    SG10201606192YA|2016-07-27|2018-02-27|Mastercard Asia/Pacific Pte Ltd|A System And Method For Making Payment Within A Digital Messaging Environment|
    SG10201608094UA|2016-09-28|2018-04-27|Mastercard Asia/Pacific Pte Ltd|Payment Facilitation Device And Payment Facilitation Method|
    US11170373B2|2016-10-21|2021-11-09|Mastercard International Incorporated|Single screen mobile checkout|
    US10878408B1|2017-02-14|2020-12-29|Wells Fargo Bank, N.A.|Mobile wallet for non-tokenized cards|
    US11049101B2|2017-03-21|2021-06-29|Visa International Service Association|Secure remote transaction framework|
    US11062388B1|2017-07-06|2021-07-13|Wells Fargo Bank, N.A|Data control tower|
    US11188887B1|2017-11-20|2021-11-30|Wells Fargo Bank, N.A.|Systems and methods for payment information access management|
    US20190220850A1|2018-01-12|2019-07-18|Mastercard International Incorporated|Systems and Methods for Use in Pairing Electronic Wallets|
    US11250414B2|2019-08-02|2022-02-15|Omnyway, Inc.|Cloud based system for engaging shoppers at or near physical stores|
    US10992606B1|2020-09-04|2021-04-27|Wells Fargo Bank, N.A.|Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets|
    法律状态:
    2020-08-11| B15I| Others concerning applications: loss of priority|Free format text: PERDA DA PRIORIDADE US 61/372,955 DE 12/08/2010 E US 61/468,847 DE 29/03/2011 REIVINDICADAS NO PCT/US2011/047678 DEVIDO A NAO APRESENTACAO DO CONTEUDO DO DOCUMENTO DE PRIORIDADE JUNTO AO REQUERIMENTO DE ENTRADA NA FASE NACIONAL E O MESMO TAMBEM NAO ESTAR DISPONIVEL NA BIBLIOTECA DIGITAL DA OMPI, CONFORME AS DISPOSICOES PREVISTAS NA LEI 9.279 DE 14/05/1996 (LPI) ART. 164O E NO ART. 26 DA RESOLUCAO INPI-PR 77/2013. |
    2020-08-18| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|
    2020-10-20| B08F| Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]|Free format text: REFERENTE A 9A ANUIDADE. |
    2020-12-08| B11B| Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements|
    2021-11-03| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    优先权:
    申请号 | 申请日 | 专利标题
    US37295510P| true| 2010-08-12|2010-08-12|
    US61/372,955|2010-08-12|
    US201161468847P| true| 2011-03-29|2011-03-29|
    US61/468,847|2011-03-29|
    PCT/US2011/047678|WO2012021864A2|2010-08-12|2011-08-12|Multi-commerce channel wallet for authenticated transactions|
    [返回顶部]